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in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 



This Technical Specification (TS) has been produced by ECMA on behalf of its members and those of the European 
Telecommunications Standards Institute (ETSI). 



Brief History 



The present document is one of a series of ECMA Standards defining services and signalling protocols applicable to 
Private Integrated Services Networks (PISNs). The series uses ISDN concepts as developed by ITU-T and conforms to 
the framework of International Standards for Open Systems Interconnection as defined by ISO/IEC. It has been 
produced under ETSI work item DTS/ECMA-00229. 

The present document specifies the Message Centre Monitoring and Mailbox Identification supplementary service. 

SS-MCM is based on SS-MWI and includes its entire functionality. The interoperability with SS-MWI is guaranteed. 
Compared to SS-MWI, SS-MCM offers an enhanced functionality for monitoring status changes of messages stored in 
the Served User's Mailbox as follows: 

• individual activation and deactivation for the monitoring of messages of different Message Type(s) within the 
Mailbox as well as interrogation of the actual SS-MCM configuration; 

• retrieval of information about all messages (i.e. new and retrieved messages) in the mailbox independent of the 

Message Status; 

• request of detailed updated information about messages stored in the mailbox at every time. 

The present document is based upon the practical experience of ECMA member companies and the results of their 
active and continuous participation in the work of ISO/IEC JTCl, ITU-T, ETSI and other international and national 
standardization bodies. It represents a pragmatic and widely based consensus. 
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Scope 



The present document specifies supplementary service Message Centre Monitoring/Mailbox Identification (SS- 
MCM/MID), which is related, but not limited, to various basic services supported by Private Integrated Services 
Networks (PISNs). Basic services are specified in ECMA-142 [2]. 

The supplementary service MCM enables a Served User to get informed by a Message Centre about the status and 
status changes of messages stored in that Served Users Mailbox. 

The supplementary service MID enables a Message Centre to identify a specific mailbox of a Served User in case that 
the Served User has more than one Mailbox within the Message Centre. In addition SS-MID enables a Served User to 
authenticate himself/herself at a specific Mailbox located within the Message Centre. 

Service specifications are produced in three stages, according to the method described in ETS 300 387 [1]. The present 
document contains the stage 1 and stage 2 specifications of SS-MCM/MID. The stage 1 specification (see clauses 6 
and 7) specifies the supplementary service as seen by users of PISNs. The stage 2 specification (see clauses 8 and 9) 
specifies the functional entities involved in the supplementary service and the information flows between them. 



Conformance 



In order to conform to the present document, a stage 3 standard shall specify signalling protocols and equipment 
behaviour that are capable of being used in a PISN which supports the supplementary service specified in the present 
document. This means that, to claim conformance, a stage 3 standard is required to be adequate for the support of those 
aspects of clauses 6 and 7 (stage 1) and clauses 8 and 9 (stage 2) which are relevant to the interface or equipment to 
which the stage 3 standard applies. 



References (normative) 



The following standards contain provisions which, through reference in this text, constitute provisions of the present 
document. All standards are subject to revision, and parties to agreements based on the present document are 
encouraged to investigate the possibility of applying the most recent editions of the standards indicated below. 

In the case of references to ECMA Standards that are aligned with ISO/IEC International Standards, the number of the 
appropriate ISO/IEC International Standard is given in brackets after the ECMA reference. 

[1] ETSI ETS 300 387: "Private Telecommunication Network (PTN); Method for the specification of 

basic and supplementary services". 

[2] ECMA-142: "Private Integrated Services Network (PISN) - Circuit-mode 64 kbit/s Bearer 

Services - Service Description, Functional Capabilities and Information Flows (International 
Standard ISO/IEC 11574)". 

[3] ECMA-241: " Private Integrated Services Network (PISN) - Specification, Functional Model and 

Information Flows - Message Waiting Indication Supplementary Service (MWISD), (International 
Standard ISO/IEC 15505)". 

[4] ITU-T Recommendation 1. 112: "Vocabulary of terms for ISDNs". 

[5] ITU-T Recommendation 1.210: "Principles of telecommunication services supported by an ISDN 

and the means to describe them". 

[6] ITU-T Recommendation Z.IOO: "Specification and Description Language (SDL)". 

[7] ECMA-133: "Private Integrated Services Network (PISN) - Reference Configuration for PISN 

Exchanges (PINX) (International Standard ISO/IEC 11579-1)". 
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4 Definitions 

For the purposes of the present document, the following terms and definitions apply. 

4.1 External definitions 

The present document uses the following terms terms and definitions given in other documents: 

Private Integrated services Network eXchange (PINX): See ECMA-133 [7]. 

Private Integrated Services Network (PISN): See ECMA-133 [7]. 

service: See ITU-T Recommendation 1.112 [4]. 

signalling: See ITU-T Recommendation 1.112 [4]. 

Supplementary Service (SS): See ITU-T Recommendation 1.210 [5]. 

telecommunication service: See ECMA-142 [2]. 

user: See ECMA-142 [2]. 

4.2 Other definitions 
4.2.1 Address Header 

The Address Header includes Originator address information and, optionally, the receiving time stamp and the priority 
of one specific message. 



4.2.2 Complete Information 

A complete list of Address Headers of either all New or all Retrieved Messages of one specific Message Type in a 
Mailbox. 

4.2.3 Compressed Information 

Includes the number of either all New or all Retrieved Messages of one specific Message Type. Optionally, in the 
compressed information the Originator address, the priority level and the time stamp of the highest priority message can 
be included. If there is more than one message of the highest priority the optional information shall be related to the 
latest received highest priority message. 

4.2.4 Deleted Messages 

A message of any Message Type which was previously stored in the Mailbox but which is not available anymore due to 
deletion by the Served User. 

4.2.5 Mailbox 

A logical entity within a Message Centre which stores all messages (New Messages and Retrieved Messages) of one or 
more Message Types for one specific Served User who is registered at the Message Centre. 
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4.2.6 Message Centre (MC) 



The entity within the network which administrates Mailboxes for Served Users. The MC provides the Served User with 
information: 

• about each incoming New Message in the Served User's Mailbox, and 

• about Message Status changes (e.g. due to retrieval or deletion) in the Served User's Mailbox, 

• by means of Complete or Compressed Information for New and Retrieved Messages. This information is 
provided by update procedures. 

4.2.7 Message Status 

Describes whether a stored message at the Served User's Mailbox is a New Message or a Retrieved Message. 

4.2.8 Message Type 

The type of a message stored at the MC. A Message Type indicates either the telecommunication service (e.g. speech, 
3,1 kHz audio, etc.) that is needed to retrieve a specific message via a PISN or the general type of a message that might 
not be directly retrieved by means of a PISN (e.g. email or video). 

4.2.9 Message Waiting Signal (MWS) 

Any type of signal presented to a Served User's terminal that is useful to draw a Served User's attention to the arrival of 
a New Message in the Served User's Mailbox. 

NOTE: The indication may be a lamp, special tone, display string etc. The technical realization of the Message 
Waiting Signal is outside the scope of the present document. 

4.2.10 New Message 

A message of any Message Type, which is stored in a Mailbox. The Served User has not yet retrieved the message. 

4.2.11 Originator 

The user who has left a message at the Served User's Mailbox. 

4.2.12 Originator address 

Address information (i.e. Party Number) of the originator. 

4.2.13 Retrieved Message 

A message of any type, which is stored in a Mailbox. The Served User has already retrieved but not deleted the message 
(i.e. the message is no longer a New Message). 

4.2.14 Served User 

The owner of a specific Mailbox at a Message Centre. The Served User receives an indication about status changes of 
the messages in the Served User's Mailbox from the Message Centre. 
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List of acronyms 



For the purposes of the present document the following acronyms apply: 

ANF-CIDL Call Identification and Call Linkage 

ANF-PR Path Replacement 

ANF-PUMI Private User Mobility Incoming Call 

ANF-PUMO Private User Mobility Outgoing Call 

ANF-RRC Route Restriction Class 

ANF-TC Transit Counter 

FE Functional Entity 

ISDN Integrated Services Digital Network 

MC Message Centre 

MCM Message Centre Monitoring 

MID Mailbox IDentification 

MWI Message Waiting Indication 

PINX Private Integrated services Network eXchange 

PISN Private Integrated Services Network 

SDL Specification and Description Language 

SS Supplementary Service 

S S - AOC Advice of Charge 

SS-CCBS Completion of Calls to Busy Subscribers 

S S -CCNR Completion of Calls on No Reply 

SS-CD Call Deflection 

SS-CFB Call Forwarding Busy 

SS-CFNR Call Forwarding No Reply 

SS-CFU Call Forwarding Unconditional 

SS-CI Call Intrusion 

SS-CINT Call INTerception 

SS-CLIP Calling Line Identification Presentation 

SS-CLIR Calling/Connected Line Identification Restriction 

SS-CMN Common Information 

SS-CNIP Calling Name Identification Presentation 

SS-CNIR Calling/Connected Name Identification Restriction 

SS-CO Call Offer 

SS-COLP Connected Line Identification Presentation 

SS-CONP Connected Name Identification Presentation 

SS-CPI(P) Call Priority Interruption (Protection) 

SS-CT Call Transfer 

SS-DND Do Not Disturb 

SS-DNDO Do Not Disturb Override 

SS-MCR Make Call Request 

SS-MID Mailbox Identification 

SS-MWI Message Waiting Indication 

SS-PUMR Private User Mobility Registration 

SS-RE REcall 

SS-SD Simple Dialog 

SS-SMS Short Message Service 

SS-SSCT Single Step Call Transfer 

SS-WTAN Wireless Terminal Authentication of the PISN 

SS-WTAT Wireless Terminal Authentication of a WTM User 

SS-WTLR Wireless Terminal Location Registration 

SS-WTMI Wireless Terminal Incoming Call 

SS-WTMO Wireless Terminal Outgoing Call 
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6 SS-MCM stage 1 specification 

6.1 Description 

6.1.1 General description 

The supplementary service MCM enables a Message Centre to inform a registered Served User about the status and 
status changes of messages stored in this Served Users Mailbox. This can be due to the arrival of New Messages or the 
change of the Message Status of stored messages (e.g. retrieval or deletion of messages). Additionally the Served User 
can request the current status of the messages in the Mailbox from the Message Centre. 

If there are New Messages for the Served User stored in the Mailbox a Message Waiting Signal may be set at the 
Served User's terminal. 

Additionally a Served User might activate, deactivate or interrogate Message Centre Monitoring individually for the 
different Message Types. 

NOTE 1: The procedures for how the Served User accesses the messages stored in the MC is outside the scope of 
the present document. 

NOTE 2: The procedures for how a message can be left in a Served User's Mailbox is outside the scope of the 
present document. 

SS-MCM is based on SS-MWI (ECMA-241 [3]) and includes its entire functionality. Therefore the interoperability 
with SS-MWI is guaranteed. Compared to SS-MWI, SS-MCM offers an enhanced functionality for monitoring status 
changes of messages stored in the Served User's Mailbox as follows: 

• individual activation and deactivation for the monitoring of messages of different Message Type(s) within the 
Mailbox as well as interrogation of the actual SS-MCM configuration; 

• retrieval of information about all messages (i.e. New and Retrieved Messages) in the mailbox independent of 

the Message Status; 

• request of detailed updated information about messages stored in the Mailbox. 

6.1 .2 Qualifications on applicability to telecommunication services 

This supplementary service does not apply directly to any basic telecommunication service. However, MCM relates to a 
basic service for which there are messages stored in the Served User's Mailbox. 

6.2 Procedures 

6.2.1 Provision/withdrawal 

SS-MCM may be provided or withdrawn after pre-arrangement with the service provider or may be generally available 
to all users. 

6.2.2 Normal procedures 

6.2.2.1 Activation, deactivation and interrogation 

In general, SS-MCM shall be available for all Served Users in a default configuration as arranged by the service 
provider. The default configuration defines the messages (i.e. a set of Message Types) which can be stored in principle 
in a Served User's Mailbox. The default configuration also defines whether complete information or compressed 
information about the messages of each specific Message Type is sent to the Served User. 
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By sending an appropriate indication to the MC the Served User can individually modify the configuration in the 
following manner: 

• activation of either one or more of the predefined Message Types so that changes in the Mailbox of that 
activated Message Types will be presented to the Served User. After that the MC shall perform the Update 
procedure as described in clause 6.2.2.2.2; 

• deactivation of either one or more of predefined Message Types so that changes in the Mailbox of that 
deactivated Message Types will not be presented to the Served User anymore. After that the MC shall perform 
the Update procedure as described in clause 6.2.2.2.2. In addition, an indication shall be given to the Served 
User stating that no information about New Messages or Retrieved Messages of this Message Type will be 
presented to the Served User while monitoring is deactivated; 

• changing of the presentation style of SS-MCM information from complete information to compressed 
information or from compressed information to complete information for a specific Message Type. 

NOTE: The change from compressed information to complete information (and vice versa) for a specific 
Message Type is only possible if the MC supports this option. 

Re-setting of all the changed SS-MCM parameters to the default configuration. 

In addition, the Served User can interrogate at the MC to get information about the actual configuration of SS-MCM. 
This means, that the Served User receives an actual list of all different Message Types (i.e. the kind of messages) from 
the MC, which can be presented to the Served User together with an indication whether the Served User gets the 
complete information or only the compressed information about the stored messages of the specific Message Type(s). 

All described changes of the default configuration shall be initiated from the Served User (and confirmed with an 
appropriate indication by the MC) by using an already existing connection or by setting up a new call independent 
connection. Release of the call independent connection is the responsibility of the Served User. 

6.2.2.2 Invocation and operation 

SS-MCM enables a MC to send status information to a Served User about messages stored in the Mailbox of the Served 
User. 

All information shall be delivered between the MC and the Served User by using an already existing connection or by 
setting up a new call independent connection. Release of the call independent connection is the responsibility of its 
initiator. 

The clauses below describe this behavior in detail. 

6.2.2.2.1 Incoming New Message 

Upon receipt of a new message in the Mailbox, the MC shall send an indication through the PISN towards the Served 
User with the following information: 

• the address of the Served User; 

• the Message Type of the specific New Message; 

• optionally, the address of the Message Centre. 

In addition to that, and depending on the presentation style that was selected in the configuration for New Messages of 
that specific Message Type (i.e. compressed or complete information), the following information shall be delivered 
through the PISN towards the Served User by the MC: 

• Compressed Mode: 

the number of New Messages waiting for that specific Message Type; 

optionally, the priority of the latest highest priority message waiting for that specific Message Type; 

optionally, the address of the user that left the latest highest priority message; 

optionally, the time when the latest highest priority message was left. 
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• Complete Mode: 

optionally, the number of New Messages waiting for that specific Message Type; 

the address of the user that left the last incoming message; 

optionally, the priority of the last incoming message; 

optionally, the time of the last incoming message. 

NOTE 1: This structure is the same as the corresponding information specified in SS-MWI. 

If the Complete Mode was selected for a specific Message Type each arrival of a New Message shall be reported to the 
Served User. If the Compressed Mode was selected the new message arrival shall be reported by the MC using one of 
the following methods: 

• each new message is reported individually; 

• more than one message is reported by using a single indication. 

The support of compressed information is mandatory, whereas the support of complete information is optional. Storing 
of the delivered information at the Served User is optional. In the case that the originator address is NOT a PISN 
number (e.g. Message Type is "email"), only the compressed mode shall be used. 

Each receipt of New Message information from the MC shall be confirmed with an appropriate indication. In addition, a 
Message Waiting Signal shall be set (if applicable) for that specific Message Type at the Served User's terminal. 

If there are no more New Messages of a specific Message Type available in the mailbox (i.e. the Served User has 
retrieved all messages of a specific Message Type), the MC shall send an indication through the PISN towards the 
Served User. This indication shall contain the following information: 

• the address of the Served User; 

• the Message Type(s) for which New Message(s) are no longer available; 

• optionally, the address of the Message Centre. 

NOTE 2: This structure is the same as the corresponding information specified in SS-MWI. 

This indication shall be confirmed and the Message Waiting Signal at the Served User's terminal, if any, shall be 
cancelled for that specific Message Type(s). 

6.2.2.2.2 Update of Message Centre Information 

Whenever the number of new and/or retrieved messages in a Mailbox changes, excluding the arrival of a New Message 
(e.g. the Served User has retrieved one or more of the new messages or has deleted one or more messages), the Message 
Centre shall inform the Served User by sending an updated list of all new and/or retrieved messages (i.e. update 
procedure). The update information shall include: 

the address of the Message Centre; 

the address of the Served User; 

the Message Type of the messages for that specific update procedure; 

either Complete Information about New and/or Retrieved Messages; or 

Compressed Information about New and/or Retrieved Messages; or 

a mixture of both, e.g. Complete Information for New Messages and Compressed Information for Retrieved 
Messages as defined in the actual configuration of SS-MCM. 

NOTE 1 : The procedures for how the Served User retrieves the content of messages and how the Served User can 
delete messages in the Mailbox is out of the scope of the present document. 
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The update procedure shall be based on the Message Type. The information for the next Message Type shall only be 
transmitted after the update information for all new and/or retrieved messages of one specific Message Type has been 
completely transmitted to the Served User. Each update procedure shall be confirmed with an appropriate indication. 

NOTE 2: The default style (Compressed or Complete Information), which is used for the update procedure of the 
various Message Type(s), is implementation dependent and will be pre-defined by the service provider. 

At the end of the update procedure the Message Waiting Signal at the Served User's terminal, if available, shall be 
refreshed for the various Message Types. 

6.2.2.2.3 Update request from the Served User 

At any time the Served User can request the Message Centre to send update information for either all available message 
types or only for one specific Message Type. To request an update for a Mailbox at the MC the following information 
from the Served User shall be sent towards the MC: 

• address of the Served User (i.e. Party Number); 

• the Message Type(s) for which the Served User requests an update; 

• optionally, the address of the Message Centre (e.g. Party Number). 

After this request the Message Centre shall answer the Served User request with information about the status of the 
New Messages in the Served User's Mailbox of the requested Message Type(s). Depending on the presentation style 
(i.e. compressed or complete information), which is adopted in the current configuration for the New Messages, the MC 
shall provide the Served User with the following information: 

• Compressed Mode: 

Message Type for which the Served User has requested an update; 

optionally, the address of the Message Centre; 

optionally, the number of New Messages waiting for that specific Message Type; 

optionally, the priority of the latest highest priority New Message waiting for that specific Message 
Type; 

optionally, the address of the user that left the latest highest priority New Message; 

optionally, the time when the latest highest priority New Message was left. 

• Complete Mode: 

Message Type for which the Served User has requested an update; 

optionally, the number of New Messages waiting for that specific Message Type. 

NOTE: This structure is the same as the corresponding information specified in SS-MWI. After sending this 
information the MC shall start the update procedure as described in clause 6.2.2.2.2. 

6.2.2.2.4 Mailbox - full indication 

Whenever the Served User's Mailbox reaches its storing capacity (or a specific threshold value) for one or more 
Message Types, the MC may send a Mailbox-full indication for specific Message Types towards the Served User. The 
Mailbox-full indication shall be sent independently of all other monitoring procedures. 

6.2.3 Exceptional procedures 

6.2.3.1 Activation, deactivation and interrogation 

The Served User shall get an appropriate error indication if: 

• the Served User wants to communicate with the MC but has no access from the service provider; 
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• a specific Message Type is requested by the Served User but not provided by the MC; 

• a specific presentation style (i.e. compressed and/or complete information) for messages of a specific Message 
Type requested from the Served User is not provided by the MC. 

6.2.3.2 Invocation and operation 

The Served User shall get an appropriate error indication if: 

• the Served User wants to communicate with the MC but has no access from the service provider; 

• a specific Message Type is requested by the Served User but not provided by the MC; 

• a specific presentation style (i.e. compressed and/or complete information) for messages of a specific Message 
Type requested from the Served User is not provided by the MC. 

6.3 Interactions with other Supplementary Services/Additional 
Network Features 

Interactions with other supplementary services and ANFs for which PISN standards were available at the time of 
publication of the present document are specified below. 

6.3.1 Calling Line Identification Presentation (SS-CLIP) 

No interaction. 

6.3.2 Connected Line Identification Presentation (SS-COLP) 

No interaction. 

6.3.3 Calling/Connected Line Identification Restriction (SS-CLIR) 

No interaction. 

6.3.4 Calling Name Identification Presentation (SS-CNIP) 

No interaction. 

6.3.5 Calling/Connected Name Identification Restriction (SS-CNIR) 

No interaction. 

6.3.6 Connected Name Identification Presentation (SS-CONP) 

No interaction. 

6.3.7 Call Forwarding Unconditional (SS-CFU) 

No interaction. 

6.3.8 Call Forwarding Busy (SS-CFB) 

No interaction. 
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6.3.9 Call Forwarding No Reply (SS-CFNR) 

No interaction. 

6.3.10 Path Replacement (ANF-PR) 

No interaction. 

6.3.11 Call Transfer (SS-CT) 

No interaction. 

6.3.12 Call Deflection (SS-CD) 

No interaction. 

6.3.1 3 Completion of Calls to Busy Subscribers (SS-CCBS) 

No interaction. 

6.3.1 4 Completion of Calls on No Reply (SS-CCNR) 

No interaction. 

6.3.15 Call Offer (SS-CO) 

No interaction. 

6.3.16 Do Not Disturb (SS-DND) 

No interaction. 

6.3.1 7 Do Not Disturb Override (SS-DNDO) 

No interaction. 

6.3.18 Call Intrusion (SS-CI) 

No interaction. 

6.3.19 Advice of Charge (SS-AOC) 

No interaction. 

6.3.20 Recall (SS-RE) 

No interaction. 

6.3.21 Call Interception (SS-CINT) 

No interaction. 

6.3.22 Transit Counter (ANF-TC) 

No interaction. 
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6.3.23 Route Restriction Class (ANF-RRC) 

No interaction. 

6.3.24 Message Waiting Indication (SS-MWI) 

No interaction. 

NOTE: SS-MCM is based on SS-MWI and includes its entire functionality. The interoperability with SS-MWI is 
therefore guaranteed. Compared to SS-MWI, SS-MCM offers an enhanced functionality for monitoring 
status changes of messages stored in the Served User's Mailbox. 

6.3.25 Wireless Terminal Location Registration (SS-WTLR) 

No interaction. 

6.3.26 Wireless Terminal Incoming Call (SS-WTMI) 

No interaction. 

6.3.27 Wireless Terminal Outgoing Call (SS-WTMO) 

No interaction. 

6.3.28 Wireless Terminal Authentication of a WTM User (SS-WTAT) 

No interaction. 

6.3.29 Wireless Terminal Authentication of the PISN (SS-WTAN) 

No interaction. 

6.3.30 Common Information (SS-CMN) 

No interaction. 

6.3.31 Call Priority Interruption (Protection) (SS-CPI(P)) 

No interaction. 

6.3.32 Private User Mobility Incoming Call (ANF-PUMI) 

No interaction. 

6.3.33 Private User Mobility Outgoing Call (ANF-PUMO) 

No interaction. 

6.3.34 Private User Mobility Registration (SS-PUMR) 

No interaction. 

6.3.35 Single Step Call Transfer (SS-SSCT) 

No interaction. 
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6.3.36 Simple Dialog (SS-SD) 

No interaction. 

6.3.37 Call Identification and Call Linkage (ANF-CIDL) 

No interaction. 

6.3.38 Short Message Service (SS-SMS) 

No interaction. 

6.3.39 Make Call Request (SS-MCR) 

No interaction. 

6.3.40 Mailbox Identification (SS-MID) 

If SS-MID is used in conjunction with SS-MCM and if mailbox identification services offered by SS-MID fail, it is 
implementation dependent if the services of SS-MCM are executed. If authentication services offered by SS-MID fail, 
the activation, deactivation, interrogation and update request services of SS-MCM shall not be executed. 

6.4 Interworking considerations 

Interworking with other networks is optional, if the other network provides similar services. 

6.5 Overall SDL 

The figure 1 contains the dynamic description of the SS-MCM activation, deactivation and interrogation procedures and 
figure 2 contains the dynamic description of SS-MCM normal operation procedure using the Specification and 
Description Language (SDL) defined in ITU-T Recommendation Z.IOO [6]. 

Input signals from the left and output signals to the left represent primitives from and to the Message Centre. 

Input signals from the right and output signals to the right represent primitives from and to the Served User. 
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Figure 1: SS-MCM Overall SDL: activation, deactivation and interrogation request 
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Figure 2: SS-MCM Overall SDL: Arrival of a New Message at the MC, Update and Update Request 
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7 SS-MID stage 1 specification 

7.1 Description 

7.1.1 General description 

The supplementary service MID enables a Message Centre to identify a specific mailbox of a Served User in case that 
the Served User has more than one Mailbox within the Message Centre. In addition SS-MID enables a Served User to 
authenticate himself/herself at a specific Mailbox located within the Message Centre. 

7.1 .2 Qualifications on applicability to telecommunication services 

This supplementary service does not apply directly to any basic telecommunication service. 

7.2 Procedures 

7.2.1 Provision/withdrawal 

SS-MID may be provided or withdrawn after pre-arrangement with the service provider or may be generally available 
to all users. 

7.2.2 Normal procedures 

7.2.2.1 Activation, deactivation and interrogation 

Not applicable. 

7.2.2.2 Invocation and operation 

7.2.2.2.1 Identification 

In case the Served User has more than one mailbox at the MC, the MC shall identify a specific mailbox by sending the 
following mailbox identification data to the Served User: 

• the address of the Message Centre where the Mailbox of the Served User is located; 

• the address of the Served User; 

• optionally, the Name of the Served User; 

• the Served User's Mailbox identity (e.g. alphanumeric string). 

The receipt of this information shall be confirmed with an appropriate indication to the MC. 

7.2.2.2.2 Authentication 

SS-MID enables a Served User to authenticate himself/herself at a specific Mailbox by sending the following address 
and authentication data to the MC: 

• the address of the Message Centre where the Mailbox of the Served User is located; 

• the address of the Served User; 

• optionally, the Name of the Served User; 

• optionally, a Served User's Mailbox identity (e.g. alphanumeric string); 
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• an authentication string (i.e. password) from the Served User to identify himself/herself at the Mailbox. 

After a successful verification of the Served User's password the MC shall confirm this to the Served User with an 
appropriate indication. 

All information shall be delivered between the Served User and the MC by using an already existing connection or by 
setting up a new call independent connection. Release of the call independent connection is the responsibility of its 
initiator. 

7.2.3 Exceptional procedures 

7.2.3.1 Activation, deactivation and interrogation 

Not applicable. 

7.2.3.2 Invocation and operation 

If an invalid mailbox identity is received from the MC an appropriate error indication shall be sent towards the Message 
Centre. 

If an invalid Served User password is received at the MC, the MC shall indicate the authentication failure by sending an 
appropriate error indication towards the Served User. 

7.3 Interactions with other Supplementary Services / Additional 
Network Features 

Interactions with other supplementary services and ANFs for which PISN standards were available at the time of 
publication of the present document are specified below. 

7.3.1 Calling Line Identification Presentation (SS-CLIP) 

No interaction. 

7.3.2 Connected Line Identification Presentation (SS-COLP) 

No interaction. 

7.3.3 Calling/Connected Line Identification Restriction (SS-CLIR) 

No interaction. 

7.3.4 Calling Name Identification Presentation (SS-CNIP) 

No interaction. 

7.3.5 Calling/Connected Name Identification Restriction (SS-CNIR) 

No interaction. 

7.3.6 Connected Name Identification Presentation (SS-CONP) 

No interaction. 

7.3.7 Call Forwarding Unconditional (SS-CFU) 

No interaction. 
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7.3.8 Call Forwarding Busy (SS-CFB) 

No interaction. 

7.3.9 Call Forwarding No Reply (SS-CFNR) 

No interaction. 

7.3.10 Path Replacement (ANF-PR) 

No interaction. 

7.3.11 Call Transfer (SS-CT) 

No interaction. 

7.3.12 Call Deflection (SS-CD) 

No interaction. 

7.3.1 3 Completion of Calls to Busy Subscribers (SS-CCBS) 

No interaction. 

7.3.1 4 Completion of Calls on No Reply (SS-CCNR) 

No interaction. 

7.3.15 Call Offer (SS-CO) 

No interaction. 

7.3.16 Do Not Disturb (SS-DND) 

No interaction. 

7.3.1 7 Do Not Disturb Override (SS-DNDO) 

No interaction. 

7.3.18 Call Intrusion (SS-CI) 

No interaction. 

7.3.19 Advice of Charge (SS-AOC) 

No interaction. 

7.3.20 Recall (SS-RE) 

No interaction. 

7.3.21 Call Interception (SS-CINT) 

No interaction. 
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7.3.22 Transit Counter (ANF-TC) 

No interaction. 

7.3.23 Route Restriction Class (ANF-RRC) 

No interaction. 

7.3.24 Message Waiting Indication (SS-MWI) 

No interaction. 

7.3.25 Wireless Terminal Location Registration (SS-WTLR) 

No interaction. 

7.3.26 Wireless Terminal Incoming Call (SS-WTMI) 

No interaction. 

7.3.27 Wireless Terminal Outgoing Call (SS-WTMO) 

No interaction. 

7.3.28 Wireless Terminal Authentication of a WTM User (SS-WTAT) 

No interaction. 

7.3.29 Wireless Terminal Authentication of the PISN (SS-WTAN) 

No interaction. 

7.3.30 Common Information (SS-CMN) 

No interaction. 

7.3.31 Call Priority Interruption (Protection) (SS-CPI(P)) 

No interaction. 

7.3.32 Private User Mobility Incoming Call (ANF-PUMI) 

No interaction. 

7.3.33 Private User Mobility Outgoing Call (ANF-PUMO) 

No interaction. 

7.3.34 Private User Mobility Registration (SS-PUMR) 

No interaction. 

7.3.35 Single Step Call Transfer (SS-SSCT) 

No interaction. 
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7.3.36 Simple Dialog (SS-SD) 

No interaction. 

7.3.37 Call Identification and Call Linkage (ANF-CIDL) 

No interaction. 

7.3.38 Short Message Service (SS-SMS) 

No interaction. 

7.3.39 Make Call Request (SS-MCR) 

No interaction. 

7.3.40 Message Centre Monitoring (SS-MCM) 

If SS-MID is used in conjunction with SS-MCM and if mailbox identification services offered by SS-MID fail, it is 
implementation dependent if the services of SS-MCM are executed. If authentication services offered by SS-MID fail, 
the activation, deactivation, interrogation and update request services of SS-MCM shall not be executed. 

7.4 Interworking considerations 

Interworking with other networks is optional, if the other network provides similar services. 

7.5 Overall SDL 

Figure 3 contains the dynamic description of SS-MID using the Specification and Description Language (SDL) defined 
in ITU-T Recommendation Z.IOO [6]. The SDL process represents the behaviour of the network in providing SS-MID. 

Input signals from the left and output signals to the left represent primitives from and to the Message Centre. 

Input signals from the right and output signals to the right represent primitives from and to the Served User. 
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Figure 3: SS-MID Overall SDL 
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8 SS-MCM stage 2 specification 

8.1 Functional model 

8.1 .1 Functional model description 

The functional model shall comprise the following Functional Entities (FEs): 

FEl Message Centre's control entity 

FE2 Served User's control entity 

FE3 Served User Agent 

The following relationship shall exist between these FEs: 

ra between FEl and FE2 

rb between FE2 and FES 

Figure 4 shows these FEs and this relationship. 



FEl 


ra 


FE2 


rb 


FES 







Figure 4: Functional model for SS-MCM 

8.1 .2 Description of Functional Entities 

8.1 .2.1 Message Centre's control entity, FEl 

This Functional Entity: 

• receives an activation, deactivation and / or interrogation request from FE2; 

• sends a New Message indication to FE2; 

• sends updated information about New Messages and/or Retrieved Messages to FE2; 

• receives a Served User request for updated Mailbox information from FE2; 

• sends the Mailbox-full indication to FE2. 

8.1 .2.2 Served User's control entity, FE2 

This Functional Entity: 

• receives an activation, deactivation and / or interrogation request from FE3 and sends this request to FEl; 

• receives an indication about the arrival of a New Message from FEl and sends this New Message indication to 
FE3; 

• receives updated information about New Message and / or Retrieved Messages stored at the Served User's 
Mailbox from FEl and sends this updated information to FE3; 

• receives a request for updated Mailbox information from FE3 and sends this request to FEl; 

• receives a Mailbox-full indication from FEl and send this Mailbox-full indication to FE3. 
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8.1 .2.3 Served User Agent, FES 

This Functional Entity: 

sends an activation, deactivation and / or interrogation request to FE2; 

receives an indication about the arrival of a New Message in the Served User's Mailbox from FE2; 

receives updated information about New Message and/or Retrieved Messages stored at the Served User's 
Mailbox from the FE2; 

sends a request for updated Mailbox information to FE2; 

receives a Mailbox-full indication from FE2. 



8.2 



Information flows 



8.2.1 Definition of information flows 

In the tables listing the elements in information flows, the column headed "Request" indicates which of these elements 
are mandatory (M) and which are optional (O) in a request/indication information flow, and the column headed 
"Confirm" (confirmed information flows only) indicates which of these elements are mandatory (M) and which are 
optional (O) in a response/confirmation information flow. 

The information flows across rb represent information flows between two functional entities FE2 and FE3. If FE3 is 
controlled by or resides in FE2 (e.g. stimulus terminal), the information flows across rb are outside the scope of the 
present document. 



8.2.1.1 



MCM_ServiceChange 



MCM_ServiceChange is a confirmed information flow across rb from FE3 to FE2 and across ra from FE2 to FEl used 
by the Served User to activate or deactivate monitoring of one or more predefined Message Types. 

Table 1 lists the elements within the MCM_ServiceChange information flow. 

Table 1 : Content of MCMServiceChange 



Element 


Request 


Confirm 


NOTE 




activation 


deactivation 






Served User identity 


M 


M 




1 


Message Centre identity 


M 


M 




2 


List of IVIessage Types 


M 


M 




3 


Presentation style of the 
New IVIessage information 





- 




4 


Presentation style of the 
Retrieved Message 
information 









5 


Result 






M 


6 



NOTE 1: This is the Served User's Party Number (e.g. PISN number). 

NOTE 2: This element identifies the Message Centre (e.g. PISN number). 

NOTE 3: This indicates one or more Message Types (e.g. speech, email, fax) which shall be activated or 
deactivated. 



NOTE 4: This is an indication whether compressed information or complete information shall be presented to the 
Served User for the New Messages. If this element is not present the presentation style shall be used as 
defined in the default configuration. 
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NOTE 5: This is an indication whether compressed information or complete information shall be presented to the 
Served User for the Retrieved Messages. If this element is not present the presentation style shall be used 
as defined in the default configuration. 

NOTE 6: This indicates acceptance or the reason for rejection. 



8.2.1.2 



MCM_lnterrogate 



MCM_Interrogate is a confirmed information flow across rb from FE3 to FE2 and across ra from FE2 to FEl used by 
the Served User to interrogate the properties and configuration parameters for a specific Message Type. 

Table 2 lists the elements within the MCM_Interrogate information flow. 

Table 2: Content of MCMJnterrogate 



Element 


Request 


Confirm 


NOTE 


Served User identity 


M 




1 


IVIessage Centre identity 


M 




2 


IVIessage Type or List of 
l\/lessage Types 


M 


M 


3 


Information about the 
IVIessage Type or List of 
Message Types 







4 


Result 




M 


5 



NOTE 1: This is the Served User's identity (e.g. PISN number). 

NOTE 2: This element identifies the Message Centre (e.g. PISN number). 

NOTE 3: This is a specific Message Type (e.g. speech, email, fax) or a List of Message Types for which the Served 
User requests information about the predefined configuration. 

NOTE 4: This element gives information to the Served User whether the interrogated Message Type is supported 
with compressed information and/or complete information for New and/or Retrieved Messages. 

NOTE 5: This indicates acceptance or the reason for rejection. 



8.2.1.3 



MCM_NewMessage 



MCM_NewMessage is a confirmed information flow across ra from FEl to FE2 and across rb from FE2 to FE3 used to 
indicate the arrival of a New Message in the Mailbox of the Served User. The information flow request has different 
elements depending whether complete information or compressed information is provided. 

NOTE: This information flow includes the same elements as the information flow ra_MWI_Activate in SS-MWI. 

Table 3 lists the elements within the MCM_NewMessage information flow. 

Table 3: Content of MCMNewMessage 



Element 


Request 


Confirm 


NOTE 1 








compressed 
information 


Complete 
information 


Served User identity 


M 




1 


1 


Message Type 


M 




2 


2 


Number of Messages 







3 


3 


Priority 







4a 


4b 


Message Centre identity 







5 


5 


Originating number 







6a 


6b 


Timestamp 







7a 


7b 


Result 




M 


8 


8 
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NOTE 1: This is the Served User's Party Number (e.g. PISN number). 

NOTE 2: This indicates the specific Message Type of the New Message (e.g. speech, email, fax). 

NOTE 3: This indicates the total number of New Messages of a particular Message Type which are stored in the 
Mailbox of the Served User. 

NOTE 4a: This indicates the priority value for the highest priority among all New Messages stored in the Mailbox of 
a particular Message Type. 

NOTE 4b: This indicates the priority value of a specific message which was left at the Message Centre. 

NOTE 5: This element identifies the Message Centre (e.g. PISN number). 

NOTE 6a: This indicates the Party Number of the Originator that left the New Message with the highest priority 
value. 

NOTE 6b: This indicates the Party Number of the Originator that left the New Message. 

NOTE 7a: This is the time stamp for the incoming of the highest priority New Message of a particular Message Type 
within the Mailbox. 

NOTE 7b: This indicates the time when a message was left. 

NOTE 8: This indicates acceptance or the reason for rejection. 



8.2.1.4 



MCM_NoNewMessage 



MCM_NoNewMessage is a confirmed information flow across ra from FEl to FE2 and across rb from FE2 to FE3 used 
to indicate that there is no more New Message of a specific Message Type in the Mailbox of the Served User. 

NOTE: This information flow includes the same elements as the information flow ra_MWI_Deactivate in 
SS-MWI. 

Table 4 lists the elements within the MCM_NoNewMessage information flow. 

Table 4: Content of MCMNoNewMessage 



Element 


Request 


Confirm 


NOTE 


Served User identity 


M 




1 


IVIessage Type 


M 




2 


IVIessage Centre identity 







3 


Result 




M 


4 



NOTE 1: This is the Served User's Party Number (e.g. PISN number). 

NOTE 2: This is the specific Message Type of the New Message (e.g. speech, email, fax). 

NOTE 3: This element identifies the Message Centre (e.g. PISN number). 

NOTE 4: This indicates acceptance or reason for rejection. 

8.2.1.5 MCM_Updatelnfo 

MCM_UpdateInfo is a confirmed information flow across ra from FEl to FE2 and across rb from FE2 to FE3 used to 
update the information about New Messages and/or Retrieved Messages. 

Table 5 lists the elements within the MCM_UpdateInfo information flow. 
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Table 5: Content of MCM_Updatelnfo 



Element 


Request 


Confirm 


NOTE 




compressed 
information 


Complete 
information 






Served User identity 


M 


M 




1 


Message Centre identity 


M 


M 




2 


Message Type 


M 


M 




3 


List of Originator addresses of 
all New and/or Retrieved 
Messages of that Message 
Type 




M 




4 


Number of all New and/or 
Retrieved Messages of that 
Message Type 


M 






5 


Priority 










6 


Timestamp 










7 


Result 






M 


8 



NOTE 1: This is the Served User's Party Number (e.g. PISN number). 

NOTE 2: This element identifies the Message Centre (e.g. PISN number). 

NOTE 3: This indicates a particular Message Type (e.g. speech, email, fax). 

NOTE 4: This indicates the Party Number of the Originator that left a message. Not applicable in the case that the 
Originator address is an email address. The information element is mandatory for complete information 
but shall not be used in the compressed information scenario. 

NOTE 5: This indicates the total number of New Messages of a specific Message Type, which are stored in the 
Mailbox of the Served User. 

NOTE 6: This indicates a list of the priority of all New and/or Retrieved Messages which were left at the Message 
Centre. When the compressed information style is used, this is the value for the highest priority among all 
New and/or Retrieved Messages stored in the Mailbox of that particular Message Type. 

NOTE 7: This indicates a list of the time stamp when the New and/or Retrieved Messages were left. When the 

compressed information style is used, this is the timestamp for incoming New and/or Retrieved Message 
with the highest priority of that particular Message Type within the Mailbox. 

NOTE 8: This indicates acceptance or the reason for rejection. 



8.2.1.6 



MCM_UpdateReq 



MCM_UpdateReq is a confirmed information flow across rb from FE3 to FE2 and across ra from FE2 to FEl used by 
the Served User to request updated information about New Messages and/or Retrieved Messages. 

NOTE: This information flow includes the same elements as the information flow ra_MWI_Interrogate in 
SS-MWI. 

Table 6 lists the elements within the MCM_UpdateReq information flow. 
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Table 6: Content of MCM_UpdateReq 



Element 


Request 


Confirm 


NOTE 






compressed 
information 


complete 
information 




Served User identity 


M 






1 


IVIessage Type 


M 


M 


M 


2 


Number of messages 


- 








3 


Priority 


- 





- 


4 


IVIessage Centre 
identity 











5 


Originating Number 


- 





- 


6 


Timestamp 


- 





- 


7 


Result 




M 


M 


8 



NOTE 1: This is the Served User's Party Number (e.g. PISN number). 

NOTE 2: This indicates the specific Message Type of the New Message (e.g. speech, email, fax). 

NOTE 3: This indicates the total number of New Messages of a particular Message Type which are stored in the 
Mailbox of the Served User. 

NOTE 4: This indicates the priority value for the highest priority among all New Messages stored in the Mailbox of 
a particular Message Type. 

NOTE 5: This element identifies the Message Centre (e.g. PISN number). 

NOTE 6: This indicates the Party Number of the Originator that left the New Message with the highest priority 
value. 

NOTE 7: This is the time stamp for the incoming of the highest priority New Message of a particular Message Type 
within the Mailbox. 

NOTE 8: This indicates acceptance or the reason for rejection. 

8.2.1.7 MCM_Mailbox_full 

MCM_Mailbox_full is an unconfirmed information flow across ra from FEl to FE2 and across rb from FES to FE2 
used by the Message Centre to give an indication to the Served User that his/her Mailbox has reached the maximum 
storage capacity for messages of a specific Message Type. 

Table 7 lists the elements within the MCM_Mailbox_full information flow. 

Table 7: Content of MCM Mailbox full 



Element 


Request 


NOTE 


Served User identity 


M 


1 


Message Centre identity 


M 


2 


Message Type 


M 


3 



NOTE 1: This is the Served User's number (e.g. PISN number). 

NOTE 2: This element identifies the Message Centre (e.g. PISN number). 

NOTE 3: This indicates a particular Message Type (e.g. speech, email, fax). 



8.2.3 Information flow sequences 



A stage 3 standard for SS-MCM shall provide signalling procedures in support of the information flow sequences 
specified below. In addition, signalling procedures should be provided to cover other sequences arising from error 
situations, interactions with Basic Call, interactions with other supplementary services, different topologies, etc. 
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The following abbreviations are used: 

• req request; 

• ind indication; 

• resp response; 

• conf confirm. 

8.2.3.1 Service Change procedures of SS-MCM 

Figure 5 shows in generic form the information flow sequence for activation and/or deactivation of SS-MCM. 



& 



101 



(^ FE2 J 



ra_MCM_ServiceChange 



req/ind 



ra_MCM_ServiceChange 



con/res 



201 



202 



r FES J 



rb_MCM_ServiceChange 



req/ind 



rb_MCM_ServiceChange 



con/res 



301 



302 



Figure 5: Information flow sequence for activation and deactivation of SS-MCM 

8.2.3.2 Interrogation procedure of SS-MCM 



Figure 6 shows in generic form the information flow sequence for interrogation of SS-MCM. 



& 



102 



(^ FE2 ) 



ra_MCM_Interrogate 



req/ind 



ra_MCM_Interrogate 



con/res 



203 



204 



(^ FES J 



rb_MCM_Interrogate 



req/ind 



rb_MCM_Interrogate 



con/res 



303 



304 



Figure 6: Information flow sequence for interrogation of SS-MCM 
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8.2.3.3 Transmission of a NewMessage Indication 

Figure 7 shows in generic form the information flow sequence for transmission of a NewMessage indication within 
SS-MCM. 



& 



103 



104 



(^ FE2 J 



ra_MCM_NewMessage 



req/ind 



ra_MCM_NewMessage 



con/res 



205 



206 



r FES J 



rb_MCM_NewMessage 



req/ind 



rb_MCM_NewMessage 



con/res 



305 



Figure 7: Information flow sequence for transmission of a NewMessage indication 

8.2.3.4 Transmission of a NoNewMessage Indication 

Figure 8 shows in generic form the information flow sequence for transmission of a NoNewMessage indication within 
SS-MCM. 



& 



f FE2 ) 



C FES j 



105 
106 




ra_MCM_NoNewMessage 




207 
208 




rb_MCM_NoNewMessage 


k 


306 




req/ind 
ra_MCM_NoNewMessage 






req/ind 

rb_MCM_NoNewMessage 


w 




con/res 






con/res 





Figure 8: Information flow sequence for transmission of a NoNewMessage indication 



£75/ 



36 



ETSI TS 102 254 V1.1.1 (2003-08) 



8.2.3.5 Transmission of Update Information 

Figure 9 shows in generic form the information flow sequence for transmission of Update Information. 



& 



107 



108 



(^ FE2 ) 



ra_MCM_UpdateInfo 



req/ind 



ra_MCM_UpdateInfo 



con/res 



209 



210 



f FES J 



rb_MCM_UpdateInfo 



req/ind 



rb_MCM_UpdateInfo 



con/res 



307 



Figure 9: Information flow sequence for transmission of update information 

8.2.3.6 Transmission of an Update Request 

Figure 10 shows in generic form the information flow sequence for transmission of an Update Request. 



& 



109 



107 



108 



f FE2 ) 



ra_MCM_UpdateReq 



req/ind 
ra_MCM_UpdateReq 



con/res 



ra_MCM_UpdateInfo 



req/ind 



ra_MCM_UpdateInfo 



con/res 



211 



212 



209 



210 



(^ FES J 



rb_MCM_UpdateReq 



req/ind 
rb_MCM_UpdateReq 



con/res 



rb_MCM_UpdateInfo 



req/ind 



rb_MCM_UpdateInfo 



con/res 



308 



309 



307 



Figure 10: Information flow sequence for transmission of an update request 



£75/ 



37 



ETSI TS 102 254 V1.1.1 (2003-08) 



8.2.3.7 Transmission of a Mailbox-full indication 

Figure 1 1 shows in generic form the information flow sequence for transmission of a Mailbox-full indication. 



& 



110 



(^ FE2 ) 



ra_MCM_Mailbox_full 



req/ind 



213 



( FES ) 



rb_MCM_Mailbox_full 



req/ind 



310 



Figure 11 : Information flow sequence for transmission of a Mailbox-full indication 



8.3 Functional Entity actions 



8.3.1 

101 

102 

103 
104 
105 

106 
107 

108 
109 

110 

8.3.2 

201 
202 
203 
204 



Functional Entity actions of FE1 



receives ra_MCM_ServiceChange req/ind from FE2 indicating the Message Type(s) which shall 
be activated or deactivated and sends ra_MCM_ServiceChange con/res after processing the 
request 

receives ra_MCM_Interrogate req/ind from FE2 with an interrogation request and sends 
ra_MCM_Interrogate con/res including the information requested by the interrogation 

sends ra_MCM_NewMessage req/ind to FE2 in order to indicate the arrival of a New Message 

receives ra_MCM_NewMessage con/res from FE2 

sends ra_MCM_NoNewMessage req/ind to FE2 in order to indicate that no more New Messages 
of a specific Message Type are in the Served User's mailbox 

receives ra_MCM_NoNewMessage con/res from FE2 

sends ra_MCM_UpdateInfo req/ind to FE2 with updated Mailbox information due to changes in 
the Served user's Mailbox or due to an update request from the Served User 

receives ra_MCM_UpdateInfo con/res from FE2 

receives ra_MCM_UpdateReq req/ind from FE2 conveying the Served User request for updated 
information and sends ra_MCM_UpdateReq con/res with updated information about New 
Messages to FE2 

sends ra_MCM_Mailbox_full req/ind to FE2 in order to indicate that the Mailbox reached its 
storage capacity 



Functional Entity actions of FE2 



receives rb_MCM_ServiceChange req/ind from FE3 and sends ra_MCM_ServiceChange req/ind 
to FEl in order to activate or deactivate specific Message Type(s) 

receives ra_MCM_ServiceChange con/res from FEl and sends rb_MCM_ServiceChange con/res 
toFE3 

receives rb_MCM_Interrogate req/ind from FE3 and sends ra_MCM_Interrogate req/ind with the 
interrogation request to FEl 

receives ra_MCM_Interrogate con/res from FEl and sends rb_MCM_Interrogate con/res with the 
information requested by the interrogation to FE3 
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205 receives ra_MCM_NewMessage req/ind from FEl and sends rb_MCM_NewMessage req/ind to 
FE3 indicating the arrival of a New Message in the Mailbox 

206 receives rb_MCM_NewMessage con/res from FE3 and sends ra_MCM_NewMessage con/res to 
FEl 

207 receives ra_MCM_NoNewMessage req/ind from FEl and sends rb_MCM_NoNewMessage 
req/ind to FE3 indicating that are no more New Messages of a specific Message Type in the 
Mailbox 

208 receives rb_MCM_NoNewMessage con/res from FE3 and sends ra_MCM_NoNewMessage 
con/res to FEl 

209 receives ra_MCM_UpdateInfo req/ind from FEl and sends rb_MCM_UpdateInfo req/ind to FE3 
with updated Mailbox information due to changes in the Served User's Mailbox or due to an 
update request from the Served User 

210 receives rb_MCM_UpdateInfo con/res from FE3 and sends ra_MCM_UpdateInfo con/res to FEl 

211 receives rb_MCM_UpdateReq req/ind from FE3 and sends ra_MCM_UpdateReq req/ind to FEl 

212 receives ra_MCM_UpdateReq con/res from FEl and sends rb_MCM_UpdateReq con/res to FE3 

213 receives ra_MCM_Mailbox_full req/ind from FEl and sends rb_MCM_Mailbox_full req/ind to 
FE3 indicating that the Mailbox reached its storage capacity 

8.3.3 Functional Entity actions of FE3 

301 sends rb_MCM_ServiceChange req/ind to FE2 in order to activate or deactivate specific Message 
Type(s) 

302 receives rb_MCM_ServiceChange con/res from FE2 

303 sends rb_MCM_Interrogate req/ind with an interrogation request to FE2 

304 receives rb_MCM_Interrogate con/res from FE2 with the information requested by the 
interrogation 

305 receives rb_MCM_NewMessage req/ind from FE2 indicating the arrival of a New Message in the 
Mailbox and sends rb_MCM_NewMessage con/res to FE2 

306 receives rb_MCM_NoNewMessage req/ind from FE2 indicating that there are no more New 
Message of a specific Message Type in the Mailbox and sends rb_MCM_NoNewMessage con/res 
toFE2 

307 receives rb_MCM_UpdateInfo req/ind from FE2 with updated Mailbox information due to 
changes in the Served User's Mailbox or due to an update request from the Served User and sends 
rb_MCM_UpdateInfo con/res to FE2 

308 sends rb_MCM_UpdateReq req/ind to FE2 conveying Served User's request for updated mailbox 
information 

309 receives rb_MCM_UpdateReq con/res from FE2 conveying updated mailbox information about 
New Messages 

310 receives rb_MCM_Mailbox_full req/ind from FE2 indicating that the Mailbox reached its storage 
capacity 



8.4 Functional Entity behaviour 



The FE behaviours shown in clauses 8.4.1, 8.4.2 and 8.4.3 are intended to illustrate typical FE behaviour in terms of 
information flows sent and received. The behaviour of each FE is shown using the Specification and Description 
Language (SDL) defined in lUT-T Recommendation Z.IOO [6]. 
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8.4.1 Behaviour of FE1 

Figure 12 shows the normal behaviour of FEl. Output signals to the right and input signals from the right represent 
information flows to and from FE2. Input signals from the left represent indications from the Message Centre. 



MCM idle 



YES 




101 
toFE2 



activate/deactivate 

monitoring of indicated 

Message Types 



ra_MCM_ServiceChange 

con/res 

(accepted) 



101 
toFE2 



101 

from FE2 



ra_MCM_ServiceChange 
con/res 
(rejected) 



MCM idle 



Figure 12a: SDL for MCM Service Chiange Procedures for FEl, Message Centre's control entity 
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MCM idle 



ra_MCM_lnterrogation 
req/ind 



102 

from FE2 



102 
toFE2 



YES 




ra_MCM_lnterrogation 

con/res 

(accepted) 



102 
toFE2 



ra_MCM_lnterrogation 
con/res 
(rejected) 



MCM idle 



Figure 12b: SDL for MCM Interrogation Request for FE1, Message Centre's control entity 
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MCM idle 



103 
toFE2 



Internal indication 

for the income of a 

New Message 



ra_MCM_NewMessage 

req/ind 



MCM_wait 



ra_MCM_NewMessage 

con/res 

(accepted) 



104 

from FE2 



ra_MCM_NewMessage 
con/res 
(rejected) 



104 
from FE2 



Y 

MCM idle 



Figure 12c: SDL for MCM NewMessage Indication for FE1, Message Centre's control entity 
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MCM idle 



Internal indication that no 
New Messages for 

specific Message Types 
are in tfie mailbox 



105 
toFE2 



ra_MCM_NoNewMessage 

req/ind 



MCM_wait 



ra_MCM_NoNewMessage 

con/res 

(accepted) 



106 
from FE2 



ra_MCM_NoNewMessage 
con/res 
(rejected) 



106 
frorr FE2 



MCM idle 



Figure 12d: SDL for MCM NoNewMessage Indication for FE1, Message Centre's control entity 
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MCM idle 



Internal indication 

to send 
updated information 



107 
toFE2 



ra_MCM_Updatelnfo 
req/ind 



MCM_walt 



ra_MCM_Updatelnfo 

con/res 

(accepted) 



108 
from FE2 



ra_MCM_Updatelnfo 
con/res 
(rejected) 



108 

from FE2 




MCM idle 



Figure 12e: SDL for MCM Update Information for FE1, Message Centre's control entity 
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109 
toFE2 




ra_MCM_UpdateReq 

con/res 

(accepted) 



Jf^ 



109 
toFE2 



ra_MCM_UpdateReq 
con/res 
(rejected) 



MCM idle 



Figure 12f: SDL for MCM Update Request for FE1, Message Centre's control entity 



MCM idle 



Internal indication 

for a full Mailbox 



110 
toFE2 



ra_MCM_Mailbox_full 

req/ind 



MCM idle 



Figure 12g: SDL for MCM Mailbox-full Indication for FE1, Message Centre's control entity 
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8.4.2 Behaviour of FE2 

Figure 13 shows the normal behaviour of FE2. Output signals to the left and input signals from the left represent 
primitives to and from the PEL Output signals to the right and input signals from the right represent information flows 
from and to FE3. 



MCM idle 



rb_MCM_ServiceChange 
req/ind 



201 

from FES 



202 
from FE1 




ra_MCM_ServiceChange 

con/res 
(accepted) 



ra_MCM_ServiceChange 
req/ind 



MCM wait 



202 
from FE1 



201 
toFEl 



ra_MCM_ServiceChange 
con/res 
(rejected) 



202 
toFE3 



rb_MCM_ServiceChange 

con/res 

(accepted) 



202 
to FES 



rb_MCM_ServiceChange 
con/res 
(rejected) 




Figure 13a: SDL for MCM Service Change Procedures for FE2, Served User's control entity 
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MCM idle 



rb_MCM_lnterrogate 
req/ind 



203 
from FES 



204 
from FE1 




ra_MCM_lnterrogate 

con/res 

(accepted) 



204 
from FE1 



ra_MCM_lnterrogate 
con/res 
(rejected) 



204 
to FES 



rb_MCM_lnterrogate 

con/res 

(accepted) 



204 
to FES 



rb_MCM_lnterrogate 
con/res 
(rejected) 



T 

MCM idle 



Figure 13b: SDL for MCM Interrogation Request for FE2, Served User's control entity 
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MCM idle 



205 
from FE1 



ra_MCM_NewMessage 

req/ind 



205 
toFE3 



rb_MCM_NewMessage 
req/ind 



i l\/ICM wait 



rb_MCM_NewMessage 

con/res 

(accepted) 



206 
from FES 



rb_MCM_NewMessage 
con/res 
(rejected) 



206 
from FES 



ra_MCM_NewMessage 

con/res 

(accepted) 



206 

toFEl 



ra_MCM_NewMessage 
con/res 
(rejected) 



206 
toFE1 



1 MCM idle 



Figure 13c: SDL for MCM NewMessage Indication for FE2, Served User's control entity 
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MCM idle 



207 
from FE1 



ra_MCM_NoNewMessage 
req/ind 



207 
to FES 



rb_MCM_NoNewMessage 

req/ind 



IVICI\/I wait 



rb_MCM_NoNewlvlessage 

con/res 

(accepted) 



ra_MCM_NoNewMessage 

con/res 
(accepted) 



208 
from FES 



208 
toFE1 



rb_MCM_NoNewlVlessage 
con/res 
(rejected) 



ra_MCM_NoNewMessage 

con/res 
(rejected) 



208 
from FES 



208 
toFE1 



MCM idle 



Figure 13d: SDL for MCM NoNewMessage Indication for FE2, Served User's control entity 
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MCM idle 



MCM update 
wait 



209 

from FE1 



ra_IVICM_Updatelnfo 
req/ind 



209 

from FE1 



ra_MCIVI_Updatelnfo 
req/ind 



209 

to FES 



rb_MCM_Updatelnfo 
req/ind 



UCM wait ! 



rb_MCM_Updatelnfo 

con/res 

(accepted) 



ra_MCM_Updatelnfo 

con/res 

(accepted) 



210 
from FE3 



210 
toFEt 



rb_MCM_Updatelnfo 
con/res 
(rejected) 



ra_MCM_Updatelnfo 
con/res 
(rejected) 



210 
from FE3 



210 

toFEl 



MCM idie 



Figure 13e: SDL for MCM Update Information for FE2, Served User's control entity 
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MCM idle 



rb_MCM_UpdateReq 

req/ind 



ra_MCM_UpdateReq 
req/ind 



l\/ICM wait 



211 
from FES 



211 

toFEl 



212 
from FE1 



212 
toFE3 



ra_MCIVI_UpdateReq 

con/res 

(accepted) 



rb_MCM_UpdateReq 

con/res 

(accepted) 



MCM update 
wait 



212 

from FE1 



212 

to FES 



ra_MCI\/l_UpdateReq 
con/res 
(rejected) 



rb_MCIVI_UpdateReq 
con/res 
(rejected) 



MCI^ idle 



Figure 13f : SDL for MCM Update Request for FE2, Served User's control entity 



MCM idle 



21S 

from FE1 



ra_MCM_Mailbox_full 
req/ind 



21S 

to FES 



rb_MCM_Mailbox_full 
req/ind 



MCM idle 



Figure 13g: SDL for MCM Mailbox-full Indication for FE2, Served User's control entity 
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8.4.3 Behaviour of FES 

Figure 14 shows the normal behaviour of FE3. Output signals to the left and input signals from the left represent 
information flows to and from the FE2. Input signals from the right represent Served User actions. 



MCM idle 



user indication for 
MCM Service Change 



rb_MCM_ServiceChange 
req/ind 



301 
toFE2 



MCM wait 



302 

from FE2 



rb_MCM_ServiceChange 

con/res 
(accepted) 



302 
from FE2 



rb_MCM_ServiceChange 
con/res 
(rejected) 



MCM idle 



Figure 14a: SDL for MCM Service Change Procedures for FES, Served User Agent 
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MCM idle 



user indication 

for 
MClVI Intrerrogate 



rb_l\/ICM_lnterrogate 
req/ind 



303 
toFE2 



MClVI wait i 



304 
from FE2 



rb_MCI\/l_lnterrogate 

con/res 

(accepted) 



304 
from FE2 



rb_MCM_lnterrogate 
con/res 
(rejected) 



MCM idle ! 



Figure 14b: SDL for MCM Interrogation Request for FES, Served User Agent 



MCM idle 



305 
from FE2 



rb_MCM_NewMessage 
req/ind 



YES 



rb_MCM_NewMessage 

con/res 

(accepted) 




rb_MCM_NewMessage 

con/res 
(rejected) 



305 
toFE2 



MCM idle 



Figure 14c: SDL for MCM NewMessage Indication for FES, Served User Agent 
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MCM idle 



306 
from FE2 



rb_MCM_NoNewMessage 
req/ind 




rb_MCM_NoNewMessage 

con/res 

(accepted) 



306 
toFE2 



rb_MCM_NoNewMessage 
con/res 
(rejected) 



306 
toFE2 



MCM idle 



Figure 14d: SDL for MCM NoNewMessage Indication for FES, Served User Agent 



307 
from FE2 



( MCM idle 



rb_MCM_Updatelnfo 
req/ind 



307 
from FE2 



MCM update 
wait 



rb_MCM_Updatelnfo 
req/ind 



YES 



rb_MCM_Updatelnfo 

con/res 

(accepted) 




307 
toFE2 



NO 



rb_MCM_Updatelnfo 
con/res 
(rejected) 



307 
toFE2 



MCM idle 



Figure 14e: SDL for MCM Update Information for FES, Served User Agent 
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MCM idle 



user indication for 
MCM Update Request 



rb_MCM_UpdateReq 
req/ind 



308 
toFE2 



MCM wait 



309 
from FE2 



rb_MCM_UpdateReq 

con/res 

(accepted) 



MCM update 
wait 



309 
from FE2 



rb_MCM_UpdateReq 
con/res 
(rejected) 



T 

MCM idie 



Figure 14f: SDL for MCM Update Request for FES, Served User Agent 



MCM idie 



310 
from FE2 



rb_MCM_Maiibox_full 
req/ind 



MCM idie 



Figure 14g: SDL for MCM Mailbox-full Indication for FES, Served User Agent 

8.5 Allocation of Functional Entities to physical equipment 

The allocation of FEs to physical locations shall apply as shown in table 8. 

Table 8: Scenarios for the allocation of FEs to physical equipment for SS-MCM 





FE1 


FE2 


FE3 


Scenario 1 


Message Centre PINX 


Served User PINX 


Terminal 



If FE3 is controlled by or resides in FE2 (e.g. stimulus terminal), the information flows between FE2 and FE3 are 
outside the scope of the present document. 
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8.6 Interworking considerations 



The allocation of FEs to physical locations in the case of interworking with other networks that support a compatible 
service shall apply as shown in table 9. 

Table 9: Scenarios for the allocation of FEs to physical equipment for SS-MCM 
in the case of interworking with other networks 





FE1 


FE2 


FE3 


Scenario 2 


IVIessage Centre PINX 


Other network 


Other network 


Scenario 3 


Other networl< 


Served User PINX 


Terminal 



9 SS-IVIID stage 2 specification 

9.1 Functional model 

9.1 .1 Functional model description 

The functional model shall comprise the following Functional Entities (FEs): 

FEl Message Centre's control entity 

FE2 Served User's control entity 

FE3 Served User Agent 

The following relationship shall exist between these FEs: 

ra between FEl and FE2 

rb between FE2 and FE3 

Figure 15 shows these FEs and this relationship. 



FEl 


ra 


FE2 


rb 


FES 







Figure 15: Functional model for SS-MID 

9.1 .2 Description of Functional Entities 

9.1 .2.1 Message Centre's control entity, FE1 

This Functional Entity: 

• sends Mailbox identification data to FE2; 

• receives Mailbox authentication data from FE2. 

9.1 .2.2 Served User's control entity, FE2 

This Functional Entity: 

• receives Mailbox identification data from FEl and sends the Mailbox identification data to FE3; 

• receives Mailbox authentication data from FE3 and sends the Mailbox authentication data to FEl. 
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9.1 .2.3 Served User Agent, FES 

This Functional Entity: 

• receives Mailbox identification data from FE2; 

• sends Mailbox authentication data to FE2. 



9.2 



Information flows 



9.2.1 Definition of information flows 

In the tables listing the elements in information flows, the column headed "Request" indicates which of these elements 
are mandatory (M) and which are optional (O) in a request/indication information flow, and the column headed 
"Confirm" (confirmed information flows only) indicates which of these elements are mandatory (M) and which are 
optional (O) in a response/confirmation information flow. 

The information flows across rb represent information flows between two functional entities FE2 and FE3. If FE3 is 
controlled by or resides in FE2 (e.g. stimulus terminal), the information flows across rb are outside the scope of the 
present document. 



9.2.1.1 



MID MailboxlD 



MID_MailboxID is a confirmed information flow across ra from FEl to FE2 and across rb from FE2 to FE3 used by the 
MC to indicate a specific Mailbox of the Served User. 

Table 10 lists the elements within the MID_MailboxID information flow. 

Table 10: Content of MID MailboxlD 



Element 


Request 


Confirm 


NOTE 


Served User identity 


M 




1 


IVIailbox identity 


M 




2 


IVIessage Centre number 


M 




3 


Served User name 







4 


Result 




M 


5 



NOTE 1: This is the Served User's Party Number (e.g. PISN number). 

NOTE 2: This identifies a particular Served User Mailbox when the Served User has different Mailboxes for 
different Message Types. 

NOTE 3: This element identifies the Message Centre (e.g. PISN number). 

NOTE 4: This is the name of the Served User. 

NOTE 5: This indicates acceptance or the reason for rejection. 



9.2.1.2 



MID MallboxAuth 



MID_MailboxAuth is a confirmed information flow across rb from FE3 to FE2 and across ra from FE2 to FEl used by 
the Served User to authenticate himself/herself at the Mailbox. 

Table 1 1 lists the elements within the MID_MailboxAuth information flow. 
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Table 11 : Content of MID MailboxAuth 



Element 


Request 


Confirm 


NOTE 


Served User identity 


M 




1 


IVIailbox identity 







2 


IVIessage Centre number 


M 




3 


Served User name 







4 


Autlientication data 


M 




5 


Result 




M 


6 



NOTE 1: This is the Served User's Party Number (e.g. PISN number). 

NOTE 2: This identifies a particular Served User Mailbox when the Served User has different Mailboxes (e.g. for 
different Message Types). 

NOTE 3: This element identifies the Message Centre (e.g. PISN number). 

NOTE 4: This is the name of the Served User. 

NOTE 5: This is the data used from the Served User to authenticate himself/herself at his/her Mailbox 
(e.g. password). 

NOTE 6: This indicates acceptance or the reason for rejection. 

9.2.2 Information flow sequences 

A stage 3 standard for SS-MID shall provide signalling procedures in support of the information flow sequences 
specified below. In addition, signalling procedures should be provided to cover other sequences arising from error 
situations, interactions with Basic Call, interactions with other supplementary services, different topologies, etc. 

The following abbreviations are used: 



ind 


indication 


resp 


response 


conf 


confirm 



9.2.2.1 Mailbox identification 

Figure 16 shows in generic form the information flow sequence for Mailbox identification. 



& 



101 



102 



ra MID MailboxID 



req/ind 



ra MID MailboxID 



con/res 



( FE2 ) 



201 



202 



f FES J 



rb MID MailboxID 



req/ind 



rb MID MailboxID 



con/res 



301 



Figure 16: Information flow sequence for transmission of mailbox identification data 
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9.2.2.2 Mailbox authentication 

Figure 17 shows in generic form the information flow sequence for Mailbox authentication. 



& 



9.3.1 

101 
102 
103 

9.3.2 

201 
202 
203 
204 

9.3.3 

301 
302 
303 



103 



(^ FE2 ) 



ra_MID_MailboxAuth 



req/ind 



ra MID MailboxAuth 



con/res 



203 



204 



(^ FES J 



rb MID MailboxAuth 



req/ind 



rb MID MailboxAuth 



con/res 



302 



303 



Figure 17: Information flow sequence for transmission of authentication data 



9.3 Functional Entity actions 



Functional Entity actions of FE1 

sends ra_MID_MailboxID req/ind with mailbox identification data to FE2 

receives ra_MID_MailboxID con/res from FE2 

receives ra_MID_MailboxAuth req/ind with authentication data from FE2 and sends 
ra MID MailboxAuth con/res to FE2 



Functional Entity actions of FE2 



receives ra_MID_MailboxID req/ind from FEl and sends rb_MID_MailboxID req/ind to FE3 
sends ra_MID_MailboxID con/res to FEl 

receives rb_MID_MailboxAuth req/ind from FE3 and sends ra_MID_MailboxAuth req/ind to FEl 
receives ra_MID_MailboxAuth con/res from FEl and sends rb_MID_MailboxAuth con/res to FE3 

Functional Entity actions of FE3 

receives rb_MID_MailboxID req/ind with mailbox identification data from FE2 
sends rb_MID_MailboxAuth req/ind with Served User's authentication data to FE2 
receives rb_MID_MailboxAuth con/res from FE2 



9.4 Functional Entity behaviour 



The FE behaviours shown in clauses 9.4.2, 9.4.2 and 9.4.3 are intended to illustrate typical FE behaviour in terms of 
information flows sent and received. The behaviour of each FE is shown using the Specification and Description 
Language (SDL) defined in lUT-T Recommendation Z.IOO [6]. 
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9.4.1 Behaviour of FE1 

Figure 18 shows the normal behaviour of FEl. Output signals to the right and input signals from the right represent 
information flows from and to FE2. Input signals from the left represent indications from the Message Centre. 



MID idle 



Indication from 
tine Message Centre 



101 
toFE2 



ra_MID_MailboxlD 
req/ind 



MID wait 



ra_MID_MailboxlD 

con/res 

(accepted) 



102 
from FE2 



ra_MID_MailboxlD 
con/res 
(rejected) 



102 

from FE2 



MID idle 



Figure 18a: SDL for transmission of identification data for Functional Entity FEl, 

lUlessage Centre's control entity 
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MID idle 



ra_MID_MailboxAuth 
req/Ind 



YES 




103 
toFE2 



ra_MID_MailboxAuth 

con/res 

(accepted) 



103 
toFE2 



ra_MID_MallboxAuth 
con/res 
(rejected) 



MID Idle 



Figure 18b: SDL for receiving authientication data for Functional Entity FE1, 
■message Centre's control entity 
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9.4.2 Behaviour of FE2 

Figure 19 shows the normal behaviour of FE2. Output signals to the left and input signals from the left represent 
primitives to and from the PEL Output signals to the right and input signals from the right represent information flows 
to and fromFE3. 



MID idle 



201 
from FE1 



ra_MID_MailboxlD 
req/ind 



201 
toFE3 



rb_MID_MailboxlD 
req/ind 



MID wait 



rb_MID_MailboxlD 

con/res 

(accepted) 



202 
from FE3 



rb_MID_MailboxlD 
con/res 
(rejected) 




ra_MID_MailboxlD 

con/res 
(accepted) 



202 

toFEl 



ra_MID_MailboxlD 
con/res 
(rejected) 



202 
toFEl 



MID idle 



Figure 19a: SDL for transmission of identification data for Functional Entity FE2, 

Served User's control entity 
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MID idle 



rb_MID_MailboxAuth 
req/ind 




ra_MID_MailboxAuth 
req/ind 



203 
toFEl 



MID wait 



204 
from FE1 



ra_MID_MailboxAuth 

con/res 

(accepted) 



204 
from FE1 



ra_MID_MailboxAuth 
con/res 
(rejected) 



204 
to FES 



rb_MID_MailboxAuth 

con/res 

(accepted) 



204 
toFE3 



rb_MID_MailboxAuth 
con/res 
(rejected) 



MID idle 



Figure 19b: SDL for transmission of authentication data for Functional Entity FE2, 

Served User's control entity 
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9.4.3 Behaviour of FES 

Figure 20 shows the normal behaviour of FE3. Output signals to the right and input signals from the right represent 
information flows to and from FE2. Input signals from the left represent Served User actions. 




rb_MID_MailboxlD 

con/res 

(accepted) 



Mailbox 

identification data 
valid ? 




301 
toFE2 



rb_MID_MallboxlD 
con/res 
(rejected) 



301 
toFE2 



MID idle 



Figure 20a: SDL for receiving identification data for Functional Entity FES, Served User Agent 
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MID idle 



MID Authentication 
request 



rb_MID_MailboxAuth 

req/ind 



302 
toFE2 



MID wait 



303 
from FE2 



rb_MID_MailboxAuth 

con/res 

(accepted) 



303 
from FE2 



rb_MID_MailboxAutfi 
con/res 
(rejected) 



MID idle 



Figure 20b: SDL for transmission of authentication data for Functional Entity FES, 

Served User Agent 

9.5 Allocation of Functional Entities to physical equipment 

The allocation of FEs to physical locations shall apply as shown in table 12. 

Table 12: Scenarios for the allocation of FEs to physical equipment for SS-MID 





FE1 


FE2 


FE3 


Scenario 1 


Message Centre PINX 


Served User PINX 


Terminal 



If FE3 is controlled by or resides in FE2 (e.g. stimulus terminal), the information flows between FE2 and FE3 are 
outside the scope of the present document. 



9.6 Interworking considerations 



The allocation of FEs to physical locations in the case of interworking with other networks that support a compatible 
service shall apply as shown in table 13. 

Table 13: Scenarios for the allocation of FEs to physical equipment for SS-MID 
in the case of interworking with other networks 





FE1 


FE2 


FES 


Scenario 2 


IVIessage Centre PINX 


Other network 


Other network 


Scenario 3 


Other networl< 


Served User PINX 


Terminal 
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